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1 . Intr oduction 

This memo is a very brief introduction to a proposed method of protection 
implementation in programmed systems, In particular, this discussion will be 
limited to an examination of the TENEX JOB, FORK and FILE objects at their 
design level. In general, this memo takes the point of view that protection 
implementation in new or existing systems should bo approached on a sound 
methodological basis. The ad-hoc transferring of 'protection mechanisms" 
from one system to another on the theory that "what is good for the goose is 
also good for the gander" is precisely what should ;;e avoided. 

We do not argue that the methodology proposed :.s in any way the only 
approach or the best approach, but only that Ad-Hoc procedures be avoided. 
There lias been a considerable amount of research intc security and protection 
in programmed system. The methodology proposed in this memo is based 
primarily on the research into "Models of Protection" by Jones [J 73] and the 
Hydra system of Wolf, et. al [W73], We believe that ,'ones' Model is general 
enough to cover a wide range of protection policies. 

In this memo we will attempt some tentative ief initions of various en- 
tities and provide some informal interpretations in the hope of provoking 
further discussion. We then introduce Jones * "Mcdel" and attempt to evaluate 
17£NEX protection from the viewpoint of that "Mod<l'\ Finally we describe the 
proposed methodology at an introductory level. 
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2« Background In formation 

The Hydra system [W73J was designed to facilitate '*the creation of 

highly secure systems". Protection is a specific consideration in the 

Hydra design philosophy: 

detection: Flexibility and protection are closely related, but 
not inversely proportional . We believe that protection is not 
merely a restrictive device imposed by 'the system* to insure 
the integrity of user operations, but is a key tool in the proper 
design of operating systems. It is essential for protection to 
exist in a uniform manner throughout the system, and not to be 
applied only to specific entities (e.g., files). The idea of 
capabilities (in the sense of Dennis [DVH66] is most important 
in the Hydra design; the kernal provides a protection facility 
for all entities in the system* This protection includes not only 
the traditional read, write, execute capabilities, but arbitrary 
protection conditions whose meaning is determined by higher -level 
software," 

The Hydra designers consider protection in the following framework: 

'•Protection is t in our view, a mechanism. A system utilizing 
that mechanism may be more or less secure depending upon policies 
governing the me of the mechanism (for example, passwords and the 
like are policy issues) and upon the reliability of the programs 
which manipulate the protected entities . Thus the design goal of 
the Hydra protection 'mechanism is to provide a set of concepts and 
facilities on which a system, with an arbitrarily high degree of 
security may be built, but not to inherently provide that security. 
A particular consequence of this philosophy has been to discard the 
notion of 'ownership*. While ownership is a useful, perhaps even 
important, concept for certain ' security • strategies, to include the 
concept at the most primitive levels would be to exclude the construc- 
tion of certain other classes of truly secure systems," 

This is a reasonable viewpoint for implementation, but in this memo it will 

be useful to talk about protection policies and protection mechanisms when 

we refer to protection. By protection policies we mean both the global 

» 

policies that a systems 1 protection mechanisms enforce and the individual 
user policies the protection mechanism enable. The Hydra designers soundly 
reject "hierarchical system structures" as a possible protection mechanism. 
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"Our rejection of hierarchical system structures, and especially 
ones which employ a single hierarchical relation for all aspects 
of system interaction, is also, in part, a consequence cf the distinction 
between protection and security. A failure to distinguish these issues 
coupled with a strict hierarchical structure leads inevitably to 
a succession of increasingly privileged system components , and 
ultimately to a "most privileged" one, which gain their privilege 
exclusively by virtue of their position in the hierarchy. Such 
structures are inherently wrong, and are at the heart of society's 
concern with computer security. Technologists like hierarchical 
structures; they are elegant, but eocperience from the real world 
shows they are not viable security structures. The problem, then, 
which liydra attempts to face squarely, is to maintain order in a 
non-hierarchical environment." 

This is a very strong viewpoint, but one which should be consider©!. 

Lampson describes an operating system (CAL-TSS[L69b]) that is tT built 

around a very powerful and general protection mechanism.'' The central 

protection mechanism in this system is called a "capability" and performs 

the following two functions: 

1. it names an object in the system 

2. it establishes a right to do certain things with the object 

The system contains a convenient method of grouping "capabilities" together 
to form classes of "capabilities" that provide "a rather flexible means for 
authorizing various things to be done without requiring the possession of a 
large number of individual capabilities." 

Freeman [F74] discusses "Protection Mechanisms and Policies in the BCC 
500 Operating System." The protection policies governing the mechanisms in 
this system are based on an "ownership" attribute. The BCC 500 's protection 
mechanisms should provide some significant insights into the pro's md con's 
of the "ownership" attribute. A more complete evaluation of these nechanisms 
is forthcoming, 

Jones [J73] defined a 'Model of Protection" that will be a verr useful 
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tool in the examination and comparison of protection abilities of various 
actual and proposed operating systems. This thesis forms the bases of 
the methodology proposed in this memo. 
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3. Protection Defined 

We adopt Jones' views on protection that specify: 

M A programmed system is a set of algorithms implemented in soft- 
ware and hardware, mapping values input to that system to output 
values. Protection is the enforcement of rules to maintain order 
during the mapping activity. To be more precise the mapping activity 
is described as a set of distinguishable processes each performing a 
sequence of algorithms defined in the programmed system. The 
processes share the use of data retaining objects. At any time each 
process is aware of a set of objects and the specified ways each 
object can be used. Order is maintained and interactions are made 
limited and predictable by rules which regulate the acquisition and 
use of access to objects. The enforcement of these rules is called 
protection." 

and establish the following: 

Limits of the protection problem- -a View from a Larger Context 

,T Protection is a part of a larger concern, called security, 
that encompasses the regulation of activity both internal and 

raal to the programmed system. A secure computer system depends 



«»«- dicuiipasses uie regulation or 
external to the programmed system, 
upon 

1. controlled access to objects within the programmed system- - 
the topic addressed within this thesis 

2. reliable hardware components 

3. prevention of threats perpetrated outside the programmed 
system, for example, monitoring or tapping communication 
lines, theft of data volumes, or illegal entry into the 
programmed system through falsified identification. 

To isolate protection from the other components of the security 
problem, we assume that all physical resources used to implement a 
computer system are completely reliable and free from external tampering, 
We assume infallible verification of the identity of users requesting 
service from the system. Since the protection component of security 
address controlling access to entities within a closed universe 
assumed to be free from any external influences, it can be studied 
« separately." 

Jones considers a "protection system" as being composed "a policy and a set 
of mechanisms built from hardware and software, the enforce and implement 
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policy." It is useful to extend these Ideas slightly to consider having 
a set of policies (where each policy is independent of every other policy 
in the sense that they do not conflict) and that the mechanisms nay 
possibly allow users to implement individualized protection policies that 
provide for more or less protection than that which is provided by ths 
basic system policies, For example, if it is a system policy that user 
directories are only accessible to the directory owner and the list of 
users the owner specifies, the mechanisms should provide for the ability to 
make a particular directory public without attaching a list of all users 
to some access directory. 
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4, Definitions 

It is convenient to be able to titter words that 'mean exactly what we 
want them to mean, nothing more and nothing less 1 . We will, of course, be 
unable to attain this goal, but will offer several definitions and informal 
remarks in order to clarify our meaning. We hope also that by doing this 
we can provoke discussions that will lead to better definitions. All of the 
definitions to be present are motivated by Jones' thesis. We will attempt 
to improve slightly on a few definitions, but will accept Jones' definitions. 
In those cases that we modify the definitions we will provide both versions. 
Definition: (Jones 1 ) Object - refers to software-defined structured encoding 

of ijnformation to which access is to be con- 
trol led as well as to physical resources 
(for example, a block of memory or a device) 
(ours) include virtual resources (for example, a 

system call and other operations that may be 
implemented in firmware or software) 
Remarks: An object is in general anything that can potentially be accessed 
and includes such things as files, subsystems, system calls, opera- 
tions, processes, processors, core,... etc. 
Definition: (Jones') Environment - a table of rights each expressed as an 

(object -name, access -name) pair restricted 
so that an access is named in a right only 
if it is applicable to the object named 
in that right. 

tAn approximate "quote" of a original Lewis Carrol idea. 
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Remarks: An "object-name" is the set of one or more global names that refer 
to a specific object. It is assuaed that each object is uniquely 
identifiable. So there may be a many to one mapping from object - 
names to an object, but not a one to many (two or more) mapping 
from object -name to object. Clearly devices like tape drives 
can be referenced by either a mneumonic name or physical device 
number . The access -name simply specifies the access rights 
that a particular environment has to a particular object. 
Naturally an access-name cannot specify execute-access to a text 
file which is not capable of being executed. 

Definition: (Jones 1 ) Type « The set of all objects is partitioned into 

equivalence classes, each called a type 
Msst people who have beer associated with the idea of time sharing have 

at least an intuitive idea of what a process is about. Nonetheless, it is 

very difficult to precisely define a process. Lampson gives one viewpoint 

which is useful [L69a], 

A process is a vehicle for the execution of programs, a logical proces- 
sor which shares the physical processor with other programs. It con- 
sists of a machine state, some resources it expends in doing work, and 
some add it tonsil structure to describe its memory and its access to objects. 

Another useful viewpoint is 'ihat a process is the smallest object in the 

system that can be independently scheduled for execution. 
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5. Introduction to Jones' 'Mxlel of Protection" 

— » ■ I ■ « « I. 1 « ■ >»——»#— WW 

Jones 1 thesis defines a very general protection model and a method of 
comparing protection policies in various operating systems. The model is 
based on "three rules that are to be bound in order to describe any 
individual system: 

- Enforcement Rule 

- Right Transfer Rule 

- Enviroisnent Binding Rule." 

A comparison method called a "suitability measure" is based on " the need- 
to-know principle; any any time a process has in its execution environment 
only those rights required to perform the current task." 

We briefly introduce the model and discuss some of the important points 
we will need later. 

5.1 The Enforcement Rule 

The Enforcement Rule specifies that a process can exercise only those 
rights which are in its current operating environment. 

In this specification the word "current" indicates that a process exists 

in different environments at different times and operating simply means that 

the process is active. Jones introduces the idea of "enforcement of protection" 

very nicely as follows: 

"A process sequentially exercises rights as specified by a program. 
In general it is possible that the program directs an executing process 
to violate protection, i,e., to exercise a right that is not in the 
execution environment. Therefore either static compile time protection 
checks or dynamic run time protection checks must be made to detect 
attempted protection violations. If a check reveals that a protection 
violation will occur, some action to avoid the violation must be taken. 
For example , in the dynamic case, execution by the offending process 
could be aborted « In the static case, the attempt to use a variable 
that is not available could cause automatic declaration of a new variable 
with the same local name. 
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A process distinguishes aa object that is to be referenced 
by using a name for it. All names that can be uttered by the 
process comprise its current name space. Because a process can 
only reference those objects for which its environment contains a 
right, we can assume that there exists one name space associated 
with each execution environment. The name interpretation function 
f £ maps the name space associated with environment E to the set of 

all objects. 

interpretation path 
f £ : {names) >{objects} 

Because name interpretation necessarily accompanies each 
exercise of a right, correlating the performance oi- name inter- 
pretation and protection checking will guarantee that all requisite 
checks are made in support of the Enforcement Rule. We assume that 
every object is uniquely identifiable, both in our discussion and in 
actual systems. For the purposes of this thesis each object is 
identified by its unique global name. (To facilitate readability of 
the following prose, no strict distinction is made between the use of 
the terms 'object' and 'global name of an object 1 , he term 'object' 
is used for either of the two.) 

The name interpretation function can be as simple as the identity 
function, if the name space of a process is the set of global names, 
©■fore complex name interpretation functions will appea* in later 
examples.) The name interpretation function itself can be used as a 
form of protection. This can be achieved by letting th* range of f« 

be a proper subset of all objects. The result is that t. process in 
E cannot access any object which is not in the range of f-, for it 

cannot name such an object. 11 

Jones limits the model to "the study of environments ldiichi are directly 
represented, i.e., there exists an encoding of environments independent of 
other types of variables in the system. The motivation for coniidering 
only direct representation is so that access to environments can be controlled 
as for any other type." Jones specifies the following three pTOtvction 
checking mechanisms that provide protection enforcement at: 

• Execution Site 

• Object Site 

• Access Site 
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5.1.1 Execution Site Protection Enforcement 

Jones states that execution site protection enforcement is the follow- 
ing: 

"A first extension of the name interpretation function incorporates 
protection checking at the beginning of the interpretation path- -the 
site of execution, where local names are generated. For each environ- 
ment there exists a capability list representation (Dennis § Van Horn 
[DVH66]). Each right in an environment E is encoded as a capability 
of the form (global object name X, access name A). f! 

The name interpretation function f~ is extended to include protection checking 

and is called F«. Jones then states that: 

'•Encoding protection data in an environment structure at the site of 
execution has the following advantages; 

1. It provides a name space (names are selectors into the capability 
list) that includes names only for objects accessible from within 
that environment, 

2. It isolates within a single data structure all protection informa- 
tion pertaining to execution in each environment. (This structure 
need only be available when execution in the environment is in 
progress.) 

# * 

3. Protection checking can be performed without leaving the execution 
site. By definition, F P prevents all violations of the Enforcement 
Rule*" tj 

We note the following disadvantages: 

1. Once an environment obtains a capability to access an object it 
must be guaranteed that the rights with respect to that object 
for that environment do not change during the time the environ- 
ment has the capability or that any change in a right is immediately 
reflected in the capability that represents it locally. 

2. It is not a viable method in instances where object -names are dynamic- 
ally generated since there is no way to know in advance what the 
name will be. For example, if the process requests the user 

to supply the name of a file to be accessed it is very doubtful 
that the capability to access that file will already exist at the 
execution site. 
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There are however many instances when this type of protection checking 
mechanism will afford efficient protected access. We do note howeveT 
that implementation of this particular type_of protection mechanism in the 
general sense of Hydra's EW73] "Local Name Space" (INS) requires a considera- 
ble amount of machinery since an LNS is uniquely associated with an invoca- 
tion of a procedure. But it is indeed possible to consider particular cases 
where this type of protection mechanism could be usefully implemented on 
existing systems. 
5.1.2 Object Site Protection Enforcement 

This form of protection simply means that protection checking is done 
at the end of the name interpretation path, it is usually implemented as 
some form of access list. 
5«i*3 Access Site Prote ction Enforcement 

Here protection is associated with some point in the path from object- 
name to access -name. An example, given by Jones, of this type of 
protection is that of type checking as provided by Algol 68 compilers. 

Jones also considers the idea of "interleaving of nsme interpretation 
and protection checking" and static verses dynamic checking. 

5.2 Right Transfer Rule 

"The Right Transfer Rule of the protection model specifies that every 
protection system must define a policy to regulate the movement of rights 
into and out of environments. In any particular system both the right trans- 
fer policy and its implementation must be bound. (This contrasts with the 
Enforcement Rule which is fixed for every protection system that th^ model 
covers, although implementations of it vary, for exajnple with the representation 
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of environments. )" Jones goes on to examine various right transfer policies 
and to specify a set of primitive operations and later "demonstrates that 
these operations do form a set of building blocks sufficient to construct 
a variety of protection policies. u 

5.3 Environment Binding Rule 

■ >■ ■ iim— tm mi wmnp i win i ihpw wmn imipn inr* iflT Tnrrnwn — r 

"The Environment Binding Rule of our model requires that each protection 
system specify how a process can cross between eroriionnents • " In this rule 
Jones considers the actions and circumstances involved in environment cross- 
ing and introduces a new primitive operation (/MPLIFY) "for cases in which 
the right transfer primitives are insufficient to describe .modification of 
a parameter right as it enters the (target) er/iro:^ent." Jones notes in 
the sunsnary that 'because parameter passage operations -ore short, well- 
defined and often executed, and therefore are candidates f<-? implementation 
in microcode or hardware." 

5.4 Suitability Measure 

Finally Jones discusses a method of comparing various protection 
systems. Jones defines an accuracy measure and a suitability factor based on 
a need-to-know principle. "This principle can be stated as; A process 
performing a task in some execution environment should have access to only 
the objects required in the performance of that task." 
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6, TENEX Objects 

This memo is limited in that it deals only with the TBffiX Job, Fork and 
File objects at a design level rather than the implementation level. TSiis 
is quite reasonable at this stage o£ the development of this series o£ memos 
and more in-depth studies will be persued as the methodology is developed 
and refined, 

6.1 Job 

In TEKEX a Job is associated with the following: 
1* The user who initiated the job 

2. An account number 

3. TTie user*s file directory 

4. A hierarchy of running and/or suspended processes 

5. A virtual memory 

Information about the job is contained in a Job Storage Block. This block 
is composed of one or more pages and is referenced by the monitor srA Exec. 
It does not appear in any user process* virtual memory. 

The user obtains a job from the job pool at login. The only information 
maintained from the last time the user performed a login is that which has 
been preserved in files. At logout all files are closed, all forks are 
deleted and the job is returned to the job pool. 

6;2 Forks 

Each job is permitted" to have sailtiple simultaneously runnable processes 
called forks. A typical fork structure is displayed in Fig. 6.2 below. 
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Parallel 
Pointer 



Superior 
Pointer 



Inferior 
Pointer 



fork handle 



Fork Table Format 



Notes: b is a subsidiary fork of a 

c, d, e are subsidiary forks of b and are parallel forks 
f , g are subsidiary forks of e and are parallel forks 

Figure 6.2 Fork Structure 



Hie top level fork in all jobs is the exec. It is possible for a fork to 
create inferior (subsidiary) forks but not parallel or superior forks in the 
structure. A fork is the smallest object in TENEX that i> individually 
scheduled for execution. Communication among forks is accomplished by: ' 
» sharing memory 

• termination, initiation, or suspension of a subsidiary fork 

• pseudo (software simulated) interrupts 

A fork may be assigned capabilities, but these in general are related 
to either the job or the user capabilities. The capabilities a fork may 
be passed are as follows: 
Job Capabilities 

process can activate terminal key PC for pssudo interrupt 
process can examine monitor tables with GECAB 
process can map the running ironitor 
process can execute protected lag functions 
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process can map privileged pages of files 

Capabilities (amplified) which can be given to an inferior whether or 
not the superior itself has them* 

process can do map operations on superior 

unprocessed PSI's cause freeze instead of texmin&tion 
User Capabilities 

user is a wheel 

user has operator privileges 

user can see system confidential information 

user can HALT TENEX 
A fork, when created is assigned an area of storage called Process Storage 
Block (PSB) , The create fork monitor call will assign the PSP and add the 
fork to the fork hierarchy in the JSB. 

6.3 Files 

In general the TENEX file system proviies b repository for information 
in the conventional sense and also gives the user access to devices not 
usually associated with files. 

In this memo we are concerned with ths protection mecka? isms available 
in TENEK. To this end we refer the reader to Appendix 1 whici contains a 
description of that protection that has besn copied from the ". , EMEX EXEC, manual. 
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7. delating the Model to TENEX Objects 

In texms of the model, all the protection mechanisms I have seen occur 
at the access site. The passing of "capabilities" to forks can be analysed 
using the models rights transfer rule. Environment Binding appears to 
occur primarily at the job level. Monitor calls are iaplemented as procedures 
and appear to be good candidates for the extension of protection along the 
lines suggested by Jones. That is monitor procedures may implement environ- 
ment binding at a low level. 
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8. TENEX Compared with the Systems Jones Goinpared 

Jones gives the following partial ordering of four systems: 
< S{0§/MVT) < SOULTICS) < S(CAL-TSS) < SCHYERA) «. 1 
where "the notation S(Z) is used to distinguish the suitability factor for 
the system called Z." We note that this partial ordering is base? in part 
on the level in which environment binding occurs, To this end thev the 
suitability scale of these systems with respect to this level is as follows: 
< S(US£R) < S(PROCESS) < S (PROCESS -PROCEDURE) < S (PROCESS -PR0OTUR1' "ALL) < 1 
Since TENEX is a job oriented system which affords more protection thai a. 
USER system but not isore than a complete process system we can locate IMC 

as follows: 

< S(OS/MVT) < SCTENEX) < S0*JLTICS) < S(CAL-TSS) < S{H*DRA) < 1 
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9. The Proposed Methodolo g y 

The proposed methodology is steply to consider each (TENEX at this time) 
system as being composed of the following three levels with respect to the 
protection function: 

• Policy 

• Logical Design 

• Implementation 

Then to analyze the policy level for logical soundness and consistency by 
using Jones' "Model of Protection'*. Next determine and be able to specify 
the mapping from policy to logical design and from logical design to 
implementation. 

This approach naturally assumes a reasonably complete documentation effort 
at each of the three levels. Since TENEX documentation presently available 
is not organized from the viewpoint of protection, our present interest is 
in providing this documentation. Once this effort is completed a detailed 
analysis of TENEX at each of the three levels can proceed, logical flaws 
or minor bugs can be noted and TENEX can be a»re accurately categorized with 
respect to protection and more realistically compared with other systems. 

Given a detailed analysis (of TENEX) alternative policies can be explored 
and the mapping process logically followed to the implementation level, giving 
sdme idea of the effort involved in a particular policy change. This method 
enables a structured, stagewise approach to the protection implementation 
problem and affords the opportunity to determine in advance the effect of 
various policy changes. 
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AHTODIX I 

Description of TENEX File Protection taken from the EXEC Itooual: 
2. File Protection 

In general, one can apply any TENEX file command to any disk 
file, no matter who it belongs to as long as one can specify 
the descriptors that make up its file designator. 
Furthermore, even when one's knowledge of these descriptors 
is incomplete, TENEX can help fill in the gaps through its 
recognition and default value features. Thus, by its 
nature, TENEX provides a very general file sharing 
capability. This leads to an equally general need for some 
way of protecting files from unauthorized access. 

To this end, TENEX provides a file protection mechanism, 
exactly balancing its file sharing capability. File 
protection is controlled by a six digit octal number 
assigned to each file at the tine of its creation. This 
number breaks down into three fields, identical in format, 
each of which can be regarded as containing two octal digits 
or six binary bits. The bits in any one of these fields 
control the following aspects of file protection. 

FILE PROTECTION FIELD 
10 Bl Wl WT B4 15 

Bit Protection Aspect Controlled 



B0 Read contents of file 

Bl Write onto file 

B2 Execute program stored in file 

B3 Append to file 

B4 Access per page rafale 

B5 Not used 
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Setting a bit 1 permits the Indicated action? setting it (1 
denies the action. Read allows information to be extracted 
from a file. Write permits new information to be written 
onto a file, replacing part or all of the original contents. 
Execute allows a file that has been read intt core memory to 
be executed as a program. Any file can be *\iade executable 
in this sense? what happens when one tries to start 
execution, of course, depends on what the file actually 
contained. Append allows new information to be added to the 
end of a file. "Fer page table" access meam that read, 
write, and execute access will be specified by the file 
itself for each individual page. The remaiAing bit is 
unused and can take on either value with no effect v 

Taking these six bits as a two digit octal number, some 
common values are: 77, which permits full access; B7, which 
protects a file from modification, but permits other 
functions? and 00 which denies everything. 

As mentioned above, a full, six digit file protection limber 
contains three of these protection fields, arranged as 
follows: 

FILE PROTECTION NUMBER 
self group others 

Working from left to right the three fields control access 
to the file by successively larger groups of users. Self 
protection governs one's own access to a file. Limiting 
one's own access permits one to protect valuable information 
from inadvertent destruction, or to protect a file from 
modification by a possibly faulty program. 

3* Directory protection 

In addition to allowing detailed specification of the access 
to file contents, TENEX also allows the contents of 
directories to be protected in a similar way. The format of 
the directory protection word is composed of three 6-bit 
fields, one field for each of "self", "group", and "others* 
similar to the file protection word. The bits have meaning 
as follows; 



Bit Protection Aspect Controlled 

B0 If off, completely prevents use of the 

directory in any way 
Bl Files may be opened subject to file protection 
B2 Owner- like functions may ba performed 

(including CONNECT) without password 
B3 Files may be added to the directory 
B4 Wot used 
B5 Not used 



The directory protection word may be changed by contacting 
the TENEX Operations Manager. 



TENSX provides a mechanism whereby users can font groups for 
the purpose of file sharing. This is useful, for example, 
where several users are collaborating on a common 
programming job and wish to share the files they are 
creating. The file group mechanism works as follows* Each 
group is assigned a number. For each user, TENIfX records a 
scries of these numbers indicating what groups he belongs 
to. Likewise, for each file directory , TEM2X records 
numbers indicating which groups have access to tin files it 
contains. Thus a given user can belong to a number of 
groups. He can make each of his directories available to 
one or more groups, which may or may not coincide with the 
groups he belongs to. The assignment of group numbers to 
users and to "file directories is 'done by the Tl'.NEX system 
ox>erators* * 

The second field in a file protection number geverns the 
powers granted when the file is accessed through the group 
mechanism. If a group member designates a file in & 
directory available to his group but belonging to another 
user, it is this protection field that controls t.\z kind of 
access granted him* 

The third protection field governs- the access panted to 
users approaching the file from outside the group rechanisra, 
i.e., all "other" users. In a typical situation* :he three 
protection fields might specify successively more stringent 
protection. For example a user might grant full .iccess to 
himself, read, execute, and append access to grouy members, 
and append only access to others, yielding yP*75404 as 
protection descriptor. 

If a user omits a protection number when creatine a disk 
file, TENEX will assign a default value, presently 777 ?54* 
This grants full access to the user and group members, read, 
execute and append access to others. The Default File 
Protecion word may be changed by contacting the T5N5X 
Operations Manager* 
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